Learnings

Outcomes

This is the first project in the GB system successfully demonstrated the WAMCS application, for Enhanced Frequency Control solution. This project successfully delivered the target latency, to trigger the required service responses within 500ms. The MCS system installed at a data centre and Local Devices are installed at NESO office at Warwick and GE office at Edinburgh. Hence the trial system demonstrated the communication link across the GB system and achieved the targeted latency. The project successfully designed the Wide Area Monitoring and Control System (WAMCS) architecture, to deliver frequency response service. 
The project has delivered: 

• The design requirements of the WAMCS, for the non-operational demonstration of Enhanced Frequency Control (EFC), have been completed and implemented. The installation of MCS systems (RA, LC, CS, LD and Emulator) was completed in the data center.  
• The communication link between PMUs from SPEN region to NESO PDC through SPEN PDC has been established. SPEN PDC to NESO PDC forward streaming of PMU data rather than aggregated stream has been established. The forward streaming method reduced the latency compared with the aggregated streaming.  
• The WAMCS built in this trial was tested for different scenarios. The test results showed that it is possible to achieve the target latency of 500ms. In these trials, the typical latency of 420ms has been achieved, with the RoCoF threshold setting of 0.3 Hz/s. It is possible to reduce the latency further by selecting suitable PMUs, centralized virtual MCS architecture.  
• In this trial, all SPEN PMUs are M-type PMUs. However, the latency from PMUs to SPEN PDC varied significantly with different PMUs. This is to be expected and can be due to the (A) Location of the site such as remote site could lead to larger latency period (B) Manufacturers and/ or design of PMUs. It is recommended to use P-type PMUs for the WAMCS applications, to reduce the latency further.  
• The trial also showed that the amount of data loss is less than 3% and this provides more confidence that a scheme deployed in this way would present very few reliability issues due to communication issues or data loss.  
• This project provided learnings on components requirements, firewall requirements and port allocation requirements to the future projects. 
• The architecture of the MCS system is designed as centralized system, whereas in the EFCC project decentralised architecture was used. The centralised MCS system was tested successfully and could be used for the future implementation.  
• The project team also completed training on PDC design and WAMC applications and this will build the NESO’s further capabilities on WAMC system applications.  
• This project also provided the learnings on future architecture requirements, EFC components required for the future implementation. 
   

The post fault frequency service Dynamic Containment (DC) is in place, for the GB system, to respond to the frequency events. For the current inertia level and system background, DC could be sufficient. As the practicality of the EFC system has been proved through this project, it can be considered as a future solution if DC and other levers prove to be insufficient. For future implementation, this project provided recommendations on architecture, EFC schemes, PMU types, communication, and firewall requirements.  

Lessons Learnt

• The centralised WAMCS approach has been developed, and this method could be used when EFC style frequency control is required for the production in future.  
• RA, CS and LC could be built as one virtual Phasor Controller that could reduce the latency values further whilst also simplifying deployment and maintenance.  
• For this demonstration purpose, 8 PMUs were available, and all of these PMUs are M-type. The latency within M-type varied with the location of the PMU and manufacturers of the PMU. To further reduce latency, low latency PMUs should be selected for the future implementation. With the P-type PMUs, instead of M-type PMUs, latency could be further reduced. For the WAMCS applications, P-type PMUs would be recommended to reduce the latency. 
• The Local Device (LD) design and the components required have been researched for this trial. The device had connectivity challenges due to the mobile connection. For the stable operation, uninterrupted internet connections are required. The data flow from MCS system to LD also had unexpectedly high data transfer in this project. These elements need to be further investigated before the future implementation.  
• The learning on firewall and port requirements for the forward streaming methods will be used for future implementation of this solution. 
• In the trial, MCS system was installed in a Data Centre due to the security constraint to place the MCS system in CNI environment. Learnings around requirements for deploying the MCS system in the CNI environment have been gained and could be used for future deployment in production. It is recommended to use Emulator for the testing purpose. However, for the deployment of this solution Emulator is not required, as PMU data could be directly fed from NESO PDC to MCS system.  
• The project setup was challenging due to the time required for the contract negotiation, in particular topics such as gaining security clearance to work in the CNI environment and delays with multi-party contracting. In this trial, MCS system was placed in the Data Centre due to the time limitations to get the required security clearance. In the future, security clearance requirements need to be planned well in advance to get the specialised personal to get the required access so that full WAMCS could be built in the CNI environment.  
• Considerations should be given to the threshold RoCoF limit required, for the given inertia of the system. It is recommended to carry out system analysis for the significant events and identified the required RoCoF threshold.  
• Mobile internet connection has lots of fluctuations and disturbance which resulted to disconnection of IPSec tunnel. For stable IPSec tunnel, uninterrupted internet connection should be considered for the Local Device operation.  
• It is recommended for phasor controller’s network interface should allow adding gateway rather defining gateway in routing page.  
  It is recommended for Original Equipment Manufacturer (OEM) to have Border Gateway Protocol (BGP) protocol support to their product. 
• It is recommended for OEM to add features of network bonding/ team and LACP to avoid single point of failure.